home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc925.txt < prev    next >
Text File  |  1994-08-01  |  31KB  |  856 lines
  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments: 925                                            ISI
  5.                                                             October 1984
  6.  
  7.                       Multi-LAN Address Resolution
  8.  
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    This memo is prompted by RFC-917 by Jeffery Mogul on "Internet
  13.    Subnets".   In that memo, Mogul makes a case for the use of "explicit
  14.    subnets" in a multi-LAN environment.  In this memo, I attempt to make
  15.    a case for "transparent subnets".  This RFC suggests a proposed
  16.    protocol for the ARPA-Internet community, and requests discussion and
  17.    suggestions for improvements.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. INTRODUCTION
  21.  
  22.    The problem of treating a set of local area networks (LANs) as one
  23.    Internet network has generated some interest and concern.  It is
  24.    inappropriate to give each LAN within an site a distinct Internet
  25.    network number.  It is desirable to hide the details of the
  26.    interconnections between the LANs within an site from people,
  27.    gateways, and hosts outside the site.  The question arises on how to
  28.    best do this, and even how to do it at all.  One proposal is to use
  29.    "explicit subnets" [1].  The explicit subnet scheme is a call to
  30.    recursively apply the mechanisms the Internet uses to manage networks
  31.    to the problem of managing LANs within one network.  In this note I
  32.    urge another approach: the use of "transparent subnets" supported by
  33.    a multi-LAN extension of the Address Resolution Protocol [2].
  34.  
  35. OVERVIEW
  36.  
  37.    To quickly review the Address Resolution Protocol (ARP).  Each host
  38.    on a broadcast LAN knows both its own physical hardware address (HA)
  39.    on the LAN and its own Internet Address (IA).  When Host-A is given
  40.    the IA of Host-B and told to send a datagram to it, Host-A must find
  41.    the HA that corresponds to Host-B's IA.  To do this Host-A forms an
  42.    ARP packet that contains its own HA and IA and the IA of the
  43.    destination host (Host-B).  Host-A broadcasts this ARP packet.  The
  44.    hosts that receive this ARP packet check to see if they are
  45.    destination sought.  If so, they (it should be only Host-B) send a
  46.    reply specifically addressed to the originator of the query (Host-A)
  47.    and supplying the HA that was needed.  The Host-A now has both the HA
  48.    and the IA of the destination (Host-B).  The Host-A adds this
  49.    information to a local cache for future use.
  50.  
  51.       Note:  The ARP is actually more general purpose than this brief
  52.       sketch indicates.
  53.  
  54.  
  55.  
  56. Postel                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 925                                                     October 1984
  61. Multi-LAN Address Resolution
  62.  
  63.  
  64.    The idea in this memo is to extend the ARP to work in an environment
  65.    of multiple interconnected LANs.
  66.  
  67.    To see how this could work let us imagine a "magic box" (BOX) that is
  68.    connected as if it were an ordinary host to two (or more) LANs.
  69.  
  70.    Hosts continue to behave exactly as they do with the basic ARP.
  71.  
  72.    When an ARP query is broadcast by any host the BOX reads it (as do
  73.    all the hosts on that LAN).  In addition to checking whether it is
  74.    the host sought (and replying if it is), the BOX checks its cache of
  75.    IA:HA address mappings in the cache that it keeps for each LAN it is
  76.    attached to.
  77.  
  78.       Case 1: If the mapping for the host is found in the cache for the
  79.       LAN that the query came from, the BOX does not respond (letting
  80.       the sought host respond for itself).
  81.  
  82.       Case 2: If the mapping for the host is found in the cache for a
  83.       different LAN than the query came from, the BOX sends a reply
  84.       giving its own HA on the LAN the query came from.  The BOX acts as
  85.       an agent for the destination host.
  86.  
  87.       Case 3: If the mapping is not found in any of the caches then, the
  88.       BOX must try to find out the the address, and then respond as in
  89.       case 1 or 2.
  90.  
  91.       In case 3, the BOX has to do some magic.
  92.  
  93.          The BOX keeps a search list of sought hosts.  Each entry
  94.          includes the IA of the host sought, the interface the ARP was
  95.          received on, and the source addresses of the original request.
  96.          When case 3 occurs, the search list is checked.  If the sought
  97.          host is already listed the search is terminated, if not the
  98.          search is propagated.
  99.  
  100.          To propagate the search, an entry is first made on the search
  101.          list, then the BOX composes and sends an ARP packet on each of
  102.          its interfaces except the interface the instigating ARP packet
  103.          was received on.  If a reply is received, the information is
  104.          entered into the appropriate cache, the entry is deleted from
  105.          the search list and a response to the search instigating ARP is
  106.          made as in case 1 or 2.  If no reply is received, give up and
  107.          do nothing -- no response is sent to the instigating host (the
  108.          entry stays on the search list).
  109.  
  110.  
  111.  
  112.  
  113. Postel                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 925                                                     October 1984
  118. Multi-LAN Address Resolution
  119.  
  120.  
  121.          To terminate the search, give up and do nothing -- no response
  122.          is sent to the instigating host (the entry stays on the search
  123.          list).
  124.  
  125.    The entries in the caches and the search list must time out.
  126.  
  127.    For every ARP request that is received, the BOX must also put the
  128.    sending host's IA:HA address mapping into the cache for the LAN it
  129.    was received on.
  130.  
  131. THE MULTI-LAN ADDRESS RESOLUTION PROTOCOL
  132.  
  133.    The plan is to use ARP just as it is.  The new element is the "magic
  134.    box" ("ARP-based bridge") that relays the ARP request into
  135.    neighboring LANs and acts as an agent for relaying datagrams to hosts
  136.    on other LANs.
  137.  
  138.    The Details
  139.  
  140.       Hosts continue to behave exactly as they do with the basic ARP.
  141.  
  142.       The LANs are connected together by BOXes (computers that are
  143.       attached to two or more LANs exactly as hosts are attached to
  144.       LANs).  The BOXes implement the following procedure.
  145.  
  146.       Each BOX keeps a table for each LAN it is connected to (or for
  147.       each LAN interface).  Entries in these tables time out, so these
  148.       tables are caches of recent information.  The entries in these
  149.       caches are the IA:HA address pairs for that LAN.
  150.  
  151.       When an ARP query is broadcast by any host the BOX reads it (as do
  152.       all the hosts on that LAN).  In addition to checking to see if it
  153.       is the host sought (and replying if it is), the BOX checks its
  154.       cache of IA:HA address mappings in the table it keeps for each LAN
  155.       it is attached to.
  156.  
  157.          Case 1: If the mapping for the host is found in the cache for
  158.          the LAN that the query came from, the BOX does not respond
  159.          (letting the sought host respond for itself).  The time out on
  160.          this entry is not reinitialized.
  161.  
  162.          Case 2: If the mapping for the host is found in the cache for a
  163.          different LAN than the query came from, the BOX sends a reply
  164.          giving its own HA on the LAN the query came from.  The time out
  165.          on this entry is not reinitialized.
  166.  
  167.             In this case the BOX is indicating that it will act as an
  168.  
  169.  
  170. Postel                                                          [Page 3]
  171.  
  172.  
  173.  
  174. RFC 925                                                     October 1984
  175. Multi-LAN Address Resolution
  176.  
  177.  
  178.             agent for the destination host.  When an IP datagram arrives
  179.             at the BOX, the BOX must attempt to forward it using the
  180.             information in its address mapping caches.
  181.  
  182.          Case 3: If the mapping is not found in any of the caches, then
  183.          the BOX must try to find out the the address, and then respond
  184.          as in case 1 or 2.  In this case, the BOX has to do some magic.
  185.  
  186.             The BOX keeps a search list of sought (but not yet found)
  187.             hosts.  Each entry includes the IA of the host sought, the
  188.             interface the ARP was received on, and the source addresses
  189.             of the original request.
  190.  
  191.             When case 3 occurs, the search list is checked.  If the
  192.             sought host is already listed the search is terminated, if
  193.             not the search is propagated.
  194.  
  195.             To propagate the search, an entry is first made on the
  196.             search list, then the BOX composes and sends an ARP packet
  197.             on each of its interfaces.  These ARP requests contain the
  198.             IA and HA of the BOX and the IA of the sought host, and
  199.             request the HA of the sought host.  If a reply is received
  200.             to the ARP request, the information is entered into the
  201.             appropriate cache, the entry is deleted from the search list
  202.             and a response to the search instigating ARP requests is
  203.             made as in case 1 or 2 above.  If no reply is received, give
  204.             up and do nothing -- no response is sent to the instigating
  205.             host (the entry stays on the search list).
  206.  
  207.                Note that the BOX must make a reasonable effort with its
  208.                ARP requests,  if it is normal for ordinary hosts to
  209.                retry ARP requests five times, then a BOX must also retry
  210.                it's ARP requests five times.
  211.  
  212.             To terminate the search, give up and do nothing -- no
  213.             response is sent to the instigating host (the entry stays on
  214.             the search list).
  215.  
  216.             There is no negative feedback from an ARP request, so there
  217.             is no way to decide that a search was unsuccessful except by
  218.             means of a time out.
  219.  
  220.       For every ARP request that is received, the BOX must also put the
  221.       sending hosts IA:HA address mapping into the cache for the LAN it
  222.       was received on.
  223.  
  224.       The entries in the caches and the search list must time out.
  225.  
  226.  
  227. Postel                                                          [Page 4]
  228.  
  229.  
  230.  
  231. RFC 925                                                     October 1984
  232. Multi-LAN Address Resolution
  233.  
  234.  
  235.       The search list must be kept and the termination rule followed to
  236.       avoid an infinite relaying of an ARP request for a host that does
  237.       not respond.  Once a host is listed in the search list, ARP
  238.       requests will not be relayed.  If a host that is down (or
  239.       otherwise not responding to ARP requests), comes up (or otherwise
  240.       begins responding to ARP requests) it will still not become
  241.       available to hosts in other LANs until the search list entry times
  242.       out.
  243.  
  244.          There are two approaches to this problem: first, to have a
  245.          relatively short time out on the search list entries; or
  246.          second, to have the BOX periodically send ARPs for each entry
  247.          on the search list.
  248.  
  249.       There are several time outs involved in this scheme.
  250.  
  251.          First, the hosts try to get the address resolved using ARP.
  252.          They may actually make several attempts before giving up if a
  253.          host is not responding.  One must have an good estimate of the
  254.          length of time that a host may keep trying.  Call this time T1.
  255.  
  256.          Second, there is the time that an entry stays on the search
  257.          list, or the time between BOX generated ARPs to resolve these
  258.          addresses.  Call this time T2.
  259.  
  260.             Note that this time (T2) must be greater than the sum of the
  261.             T1s for the longest loop of LANs.
  262.  
  263.          Third, there is the time that entries stay in the cache for
  264.          each LAN.  Call this time T3.
  265.  
  266.          The relationship must be  T1 < T2 < T3.
  267.  
  268.             One suggestion is that T1 be less than one minute, T2 be ten
  269.             minutes, and T3 be one hour.
  270.  
  271.          If the environment is very stable, making T3 longer will result
  272.          in fewer searches (less overhead in ARP traffic).  If the
  273.          environment is very dynamic making T3 shorter will result in
  274.          more rapid adaptation to the changes.
  275.  
  276.          Another possibility is to restart the timer on the cache
  277.          entries each time they are referenced, and have a small value
  278.          for T3.  This would result in entries that are frequently used
  279.          staying in the cache, but infrequently used information being
  280.          discarded quickly.  Unfortunately there is no necessary
  281.          relationship between frequency of use and correctness.  This
  282.  
  283.  
  284. Postel                                                          [Page 5]
  285.  
  286.  
  287.  
  288. RFC 925                                                     October 1984
  289. Multi-LAN Address Resolution
  290.  
  291.  
  292.          method could result in an out-of-date entry persisting in a
  293.          cache for a very long time if ARP requests for that address
  294.          mapping were received at just less than the time out period.
  295.  
  296.       When handling regular datagrams, the BOXes must decrement the IP
  297.       datagram Time-To-Live field (TTL) and update the IP header check
  298.       sum.  If the TTL becomes zero the datagram is discarded (not
  299.       forwarded).
  300.  
  301.       ARP, as currently defined, will take the most recent information
  302.       as the best and most up-to-date.  In a complicated multi-LAN
  303.       environment where there are loops in the connectivity it is likely
  304.       that one will get two (or more) responses to an ARP request for a
  305.       host on some other LAN.  It is probable that the first response
  306.       will be from the BOX that is the most efficient path.
  307.  
  308.       The one change to the host implementation of ARP that is suggested
  309.       here is to prevent later responses from replacing the mapping
  310.       recorded from the first response.
  311.  
  312.    Potential Problems
  313.  
  314.       Bad Cache Entries
  315.  
  316.          If some wrong information get into a cache entry, it will stay
  317.          there for time T3.  The persistence of old information could
  318.          prevent communication (for a time) if a host changed its IA:HA
  319.          mapping.
  320.  
  321.          One way to replace bad or out-of-date entries in a cache would
  322.          be to have the BOXes explicitly interpret a broadcast ARP reply
  323.          to require an entry with either this IA or HA to be replaced
  324.          with this new IA:HA mapping.  One could have important servers
  325.          send a broadcast ARP reply when they come up.
  326.  
  327.       Non-ARP Hosts
  328.  
  329.          It seems unrealistic to expect to use both ARP hosts and
  330.          non-ARP hosts on the same LAN and expect them to communicate.
  331.          If all the non-ARP hosts are on the same LAN the situation is
  332.          considered with under the next heading (Non-Broadcast LANs).
  333.  
  334.          Hosts that do not implement ARP must use some other means of
  335.          address mapping.  Either they hold a complete table of all
  336.          hosts, or they access some such table in a server via some
  337.          protocol; or they expect to make all routing decisions based on
  338.          analysis of address fields.
  339.  
  340.  
  341. Postel                                                          [Page 6]
  342.  
  343.  
  344.  
  345. RFC 925                                                     October 1984
  346. Multi-LAN Address Resolution
  347.  
  348.  
  349.       Non-Broadcast LANs
  350.  
  351.          BOXes that are connected to LANs that do not have broadcast
  352.          capability and/or LANs where the hosts do not respond to ARP
  353.          may have a static or dynamic table of the IA:HA mappings for
  354.          that LAN (or the addresses may be computed from one another).
  355.          All the hosts on that LAN must be in the table.
  356.  
  357.          When a BOX must find the address mapping and would otherwise
  358.          send an ARP request into a non-broadcast LAN (this can only
  359.          happen when the sought host is not the non-broadcast LAN since
  360.          all the hosts are in the table), it must instead send an ARP
  361.          type request specifically to each of the other BOXes on that
  362.          LAN.
  363.  
  364.       Size of Tables
  365.  
  366.          The worst case of the size of the tables in the BOXes is the
  367.          number of hosts in the set of LANs for each table.  That is,
  368.          the table kept for each LAN interface may (in the worst case)
  369.          grow to have an entry for each host in the entire set of LANs.
  370.          However, these tables are really caches of the entries needed
  371.          for current communication activity and the typical case will be
  372.          far from the worst case.  Most hosts will communicate mostly
  373.          with other hosts on their own LAN and with a few hosts on other
  374.          LANs.  Most communication on LANs is between work station hosts
  375.          and server hosts.  It can be expected that there will be
  376.          frequent communication involving the main server hosts and that
  377.          these server hosts will be entered in the tables of most of the
  378.          BOXes most of the time.
  379.  
  380.       Infinite Transmission Loops
  381.  
  382.          The possibility of infinite transmission loops through an
  383.          interconnected set of LANs is prevented by keeping search lists
  384.          in the BOXes and terminating the search when a request is
  385.          received for an address already on the list.
  386.  
  387.          Transmission loops of regular datagrams can not persist because
  388.          them the BOXes must decrement the TTL, and discard the datagram
  389.          if the TTL is reduced to zero.  For debugging purposes it would
  390.          be useful for a BOX to report to the implementer any datagrams
  391.          discarded for this reason.
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Postel                                                          [Page 7]
  399.  
  400.  
  401.  
  402. RFC 925                                                     October 1984
  403. Multi-LAN Address Resolution
  404.  
  405.  
  406.       Broadcast
  407.  
  408.          Note that broadcast does not really have anything to do with
  409.          either transparent subnets or explicit subnets.  Since it was
  410.          discussed in [1], it will be discussed here, too.  Two of the
  411.          three broadcast functions suggested in [1] work just the same
  412.          and have the same effects, the third can be supported, too.
  413.  
  414.          It is also argued that the support for a broadcast
  415.          interpretation of IAs is a bigger issue that the question of
  416.          explicit subnets versus transparent subnets and it should be
  417.          decided separately.
  418.  
  419.          It is also suggested that broadcast is not really what is
  420.          desired, but rather multicast is the better function.  It may
  421.          make sense to understand how to do an Internet multicast before
  422.          adopting a broadcast scheme.
  423.  
  424.          This IP Network
  425.  
  426.             If the IA of this network number and an all ones host number
  427.             (e.g., 36.255.255.255) is used, an IP level broadcast to all
  428.             hosts on this Network (all LANs) is intended.  A BOX must
  429.             forward this datagram.  A BOX must examine the datagram for
  430.             potential significance to the BOX itself.
  431.  
  432.             To prevent infinite transmission loops each BOX must keep a
  433.             list of recent broadcasts.  The entries in this list contain
  434.             the source IA and the Identification field from the datagram
  435.             header.  If a broadcast is received and matches an entry on
  436.             the list it is discarded and not forwarded.  The entries on
  437.             this list time out in time T2.
  438.  
  439.          This LAN Only
  440.  
  441.             If the IA of all ones (i.e., 255.255.255.255) is used an IP
  442.             level broadcast to all hosts on this LAN only is intended.
  443.             A BOX must not forward this datagram.  A BOX must examine
  444.             the datagram for potential significance to the BOX itself.
  445.  
  446.          Another LAN Only
  447.  
  448.             Since the LANs are not individually identified in the IA
  449.             this can not be supported in the same way. Some have also
  450.             argued that this is a silly capability to provide.
  451.  
  452.             One way to provide it is to establish a specific IA for each
  453.  
  454.  
  455. Postel                                                          [Page 8]
  456.  
  457.  
  458.  
  459. RFC 925                                                     October 1984
  460. Multi-LAN Address Resolution
  461.  
  462.  
  463.             LAN that means "broadcast on this LAN".  For example,
  464.             36.255.255.128 means broadcast on LAN A, and 36.255.255.187
  465.             means broadcast on LAN B, etc.  These addresses would be
  466.             specially interpreted by the BOXes attached to the specific
  467.             LAN where they had the special interpretation, other BOXes
  468.             would treat these address as any other IAs.   Where these
  469.             addresses are specially interpreted they are converted to
  470.             the broadcast on this LAN only address.
  471.  
  472. DISCUSSION
  473.  
  474.    The claim for the extended ARP scheme is that the average host need
  475.    not even know it is in a multi-LAN environment.
  476.  
  477.       If a host took the trouble to analyze its local cache of IA:AH
  478.       address mappings it might discover that several of the IAs mapped
  479.       to the same HA.  And if it took timing measurements it might
  480.       discover that some hosts responded with less delay that others.
  481.       And further, it might be able to find a correlation between these
  482.       discoveries.  But few hosts would take the trouble.
  483.  
  484.    Address Structure
  485.  
  486.       In the explicit subnet scheme, some IA bits are devoted to
  487.       identifying the subnet (i.e., the LAN).  The address is broken up
  488.       into network, subnet, and host fields.  Generally, when fields are
  489.       use the density of the assigned addresses in the address space
  490.       goes down.  That is, there is a less efficient use of the address
  491.       space.  Significant implementation problems may arise if more
  492.       subnets than planned are installed and it becomes necessary to
  493.       change the size of the subnet field.  It seems totally impractical
  494.       to use the explicit subnet scheme with a class C IA.
  495.  
  496.       In the extended ARP scheme the address is simply the network, and
  497.       host fields.  The extended ARP scheme may be used with any class
  498.       of IA.
  499.  
  500.    Relocating Hosts
  501.  
  502.       In the explicit subnet scheme when a host is unplugged from one
  503.       LAN and plugged into another its IA must change.
  504.  
  505.       In the extended ARP scheme it may keep the same IA.
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Postel                                                          [Page 9]
  513.  
  514.  
  515.  
  516. RFC 925                                                     October 1984
  517. Multi-LAN Address Resolution
  518.  
  519.  
  520.    One view of the situation suggests that there are really two
  521.    problems:
  522.  
  523.       1. How does the host discover if the destination is in this LAN or
  524.       some other LAN?
  525.  
  526.          This question assumes that a host should know the difference
  527.          and should do something different in the two cases, and further
  528.          that once the host knows the answer it also know how to send
  529.          the data (e.g., directly to the host, or to the box).
  530.  
  531.             The claim here is that the hosts should not know the
  532.             difference and should always do the same thing.
  533.  
  534.       2. How do the BOXes that connect LANs know which BOXes are the
  535.       routes to which LANs?
  536.  
  537.          This question assumes that the BOXes need some kind of
  538.          topological knowledge, and exchange BOX-to-BOX protocol
  539.          information about connectivity.
  540.  
  541.             The claim here is that the BOXes do not need topological
  542.             knowledge and do not need to explicitly know about the
  543.             existence of other BOXes.
  544.  
  545.    It has been suggested that there are two problems: first, how the
  546.    hosts do routing; and second, how the BOXes do routing.  A claim has
  547.    been made that the competing strategies each have an approach to each
  548.    problems and one could select a solution made up partly from one
  549.    approach and partly from another.
  550.  
  551.       For example: use ARP within the LAN and have the BOX send ARP
  552.       replies and act as a agent (as in the extended ARP scheme), but
  553.       use a BOX-to-BOX protocol to get the "which hosts are where"
  554.       information into the BOXes (as in the explicit subnet scheme).
  555.  
  556.    There are two places where code is involved: a large number of hosts,
  557.    and a small number of BOXes.  In considering the trade off between
  558.    explicit subnet scheme and extended ARP scheme, the work done in the
  559.    hosts should weigh a lot more than the work done in the BOXes.
  560.  
  561.       What do hosts do?
  562.  
  563.          Explicit Subnet Scheme
  564.  
  565.             The host must be able to decide if this IA is on this LAN or
  566.  
  567.  
  568.  
  569. Postel                                                         [Page 10]
  570.  
  571.  
  572.  
  573. RFC 925                                                     October 1984
  574. Multi-LAN Address Resolution
  575.  
  576.  
  577.             some other LAN.  If on this LAN then use some procedure to
  578.             find the HA.  If on some other LAN then use some procedure
  579.             to find the HA of a BOX.
  580.  
  581.          Extended ARP Scheme
  582.  
  583.             In every case the host uses ARP to get a IA:HA mapping.
  584.  
  585.       What do the BOXes do?
  586.  
  587.          Explicit Subnet Scheme
  588.  
  589.             The BOX must be able to decide which LAN within the site the
  590.             destination host is on.  The BOXes must have some routing
  591.             table that tells for each LAN in the site which interface to
  592.             send datagrams on.  This routing table must be kept up to
  593.             date, probably by a BOX-to-BOX protocol much like the
  594.             Internet Gateway-to-Gateway protocol.
  595.  
  596.          Extended ARP Scheme
  597.  
  598.             The BOX must keep caches for each LAN it is attached to of
  599.             IA:HA mappings, and it must keep a search list.  It does not
  600.             run any BOX-to-BOX protocol, It does not even know if any
  601.             other BOXes exist.
  602.  
  603.    Topology and Implementation Complexity
  604.  
  605.       Trees
  606.  
  607.          If the organization of the LANs and the BOXes is tree
  608.          structured, the BOXes may be very simple, they don't have to
  609.          keep the search lists at all, since there won't be any loops
  610.          for the ARP-request to traverse.
  611.  
  612.       Loops
  613.  
  614.          If the organization has loops then the search lists are
  615.          essential.  If the topology is kept balanced so that there are
  616.          no long loops (all loops are about the same size), and the LANs
  617.          are reasonably compatible in delay characteristics, then the
  618.          procedure described here will work well.
  619.  
  620.       Complex
  621.  
  622.          If the organization is very complex, topologically unbalanced,
  623.  
  624.  
  625.  
  626. Postel                                                         [Page 11]
  627.  
  628.  
  629.  
  630. RFC 925                                                     October 1984
  631. Multi-LAN Address Resolution
  632.  
  633.  
  634.          and/or composed of mix of different types of LANS with vastly
  635.          different delay characteristics, then it may be better to use a
  636.          BOX-to-BOX routing protocol.
  637.  
  638. SUMMARY
  639.  
  640.    It would be useful if the Internet community could come to some
  641.    agreement on a solution to the multi-LAN network problem and could
  642.    with a unified voice urge work station manufacturers to provide that
  643.    solution built in.
  644.  
  645.    I urge consideration of the extended ARP scheme expounded on here.
  646.  
  647.    I think that most work stations will be connected to LANs that have a
  648.    broadcast capability.  I think that most work stations will be used
  649.    in situations that do not require explicit subnets, and most will be
  650.    used in situations where a class C Internet addresses would be
  651.    appropriate (and explicit subnets impossible).  Thus, i think it
  652.    would be best to ask manufacturers to include support for ARP in work
  653.    stations off the shelf.  I also think we ought to get busy and
  654.    create, develop, test, and produce the magic boxes I suggest so that
  655.    they too are available off the shelf.
  656.  
  657.    Please note that neither this note nor [1] proposes a specific
  658.    routing procedure or BOX-to-BOX protocol.  This is because such a
  659.    routing procedure is a very hard problem.  The plan proposed here
  660.    will let us get started on using multi-LAN environments in a
  661.    reasonable way.  If we later decide on a routing procedure to be used
  662.    between the BOXes we can redo the BOXes without having to redo the
  663.    hosts.
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Postel                                                         [Page 12]
  684.  
  685.  
  686.  
  687. RFC 925                                                     October 1984
  688. Multi-LAN Address Resolution
  689.  
  690.  
  691. GLOSSARY
  692.  
  693.    ARP
  694.  
  695.       Address Resolution Protocol (see [2]).
  696.  
  697.    BOX
  698.  
  699.       Magic Box.  A box (computer) connected to two or more LANs of the
  700.       same Network.  Also called an "ARP-based bridge".
  701.  
  702.    Bridge
  703.  
  704.       A node (computer) connected to two or more administratively
  705.       indistinguishable but physically distinct subnets, that
  706.       automatically forwards datagrams when necessary, but whose
  707.       existence is not know to other hosts.  Also called a "software
  708.       repeater".
  709.  
  710.    Datagram
  711.  
  712.       The unit of communication at the IP level.
  713.  
  714.    Explicit Subnet
  715.  
  716.       A Subnet explicitly identified in the the Internet Address by a
  717.       subnet address field, and so visible to others both in side and
  718.       out side the Network.
  719.  
  720.    Gateway
  721.  
  722.       A node (computer) connected to two or more administratively
  723.       distinct networks and/or subnets, to which hosts send datagrams to
  724.       be forwarded.
  725.  
  726.    HA
  727.  
  728.       Hardware Address, the address used in a packet on a LAN.
  729.  
  730.    Host Number
  731.  
  732.       The address of a host within an Network, the low-order part of an
  733.       IA.
  734.  
  735.    IA
  736.  
  737.       Internet Address, as defined in IP.
  738.  
  739.  
  740. Postel                                                         [Page 13]
  741.  
  742.  
  743.  
  744. RFC 925                                                     October 1984
  745. Multi-LAN Address Resolution
  746.  
  747.  
  748.    Internet
  749.  
  750.       The collection of connected Internet Networks (also known as the
  751.       Catenet).  A set of interconnected networks using IP.
  752.  
  753.    IP
  754.  
  755.       Internet Protocol (see [3]).
  756.  
  757.    LAN
  758.  
  759.       Local Area Network.
  760.  
  761.    Multi-LAN Network
  762.  
  763.       A set of LANs treated as one Network, i.e., using one Network
  764.       Number in common.  The individual LANs may be either Explicit
  765.       Subnets or Transparent Subnets.
  766.  
  767.    Network
  768.  
  769.       A single Internet Network (possibly divided into subnets or
  770.       composed of multiple LANs), identified by an individual Network
  771.       Number.
  772.  
  773.    Network Number
  774.  
  775.       An IP Network Number, the high-order part of an IA.
  776.  
  777.    Packet
  778.  
  779.       The unit of communication at the LAN hardware level.
  780.  
  781.    Subnet
  782.  
  783.       A subnet of Network. A portion of a Network (either logical or
  784.       physical).
  785.  
  786.    Transparent Subnet
  787.  
  788.       A Subnet not identified in the Internet Address, and so invisible
  789.       to others, (see Multi-LAN Network).
  790.  
  791.    TTL
  792.  
  793.       The IP Time-To-Live field.
  794.  
  795.  
  796.  
  797. Postel                                                         [Page 14]
  798.  
  799.  
  800.  
  801. RFC 925                                                     October 1984
  802. Multi-LAN Address Resolution
  803.  
  804.  
  805. REFERENCES
  806.  
  807.    [1]  J. Mogul, "Internet Subnets",  RFC-917, Stanford University,
  808.         October 1984.
  809.  
  810.    [2]  D. Plummer, "An Ethernet Address Resolution Protocol or
  811.         Converting Network Protocol Addresses to 48-bit Ethernet
  812.         Addresses for Transmission on Ethernet Hardware",  RFC-826,
  813.         Symbolics, November 1982.
  814.  
  815.    [3]  J. Postel, "Internet Protocol",  RFC-791, USC-ISI,
  816.         September 1981.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854. Postel                                                         [Page 15]
  855.  
  856.